Skip to main content

Advantages of Messaging

One method of asynchronous and event-based communication between microservices is messaging. A microservice sends a message to one or more other microservices. Messages can be executed as requests, events or responses. A microservice responds to a request by sending a message back to the requesting service, which in turn processes this response asynchronously. Messaging has advantages, especially in modular and distributed systems:

Even if there is a network failure, messages can be sent once the connection has been restored by the messaging system caching them until the communication system is available again. Due to the asynchronous nature of messaging, microservices do not block while waiting for a response, but can continue to process the programme in the meantime. This leads to a more efficient architecture in systems with high latency times during communication.

The use of queues and topics in messaging systems supports the principle of loose coupling. One or more recipients register in the queues or topics of a messaging system. Messages sent by a service to these are forwarded to the registered services. The sender does not need to know the recipients of a message and vice versa.

The components of centralised messaging systems, which are responsible for managing queues and topics and forwarding messages, among other things, are referred to as brokers. Examples of messaging systems are RabbitMQ, Apache Kafka and ZeroMQ, whereby the latter does not require the use of a dedicated message broker, but rather the messages can be exchanged directly between the microservices.

The advantages of a message-based service-oriented architectures lie in the modularisation, since smaller independently developable and migratable components are easier to maintain and adapt:

  • Elimination of the single point of failure: loosely coupled components minimise the probability that a fault in one component will result in the total failure of the system.
  • Faster iterations: since only the service to be updated has to go through the process of testing and commissioning when a service is updated, the agility in the development process increases.
  • Effective scalability: Scaling at the individual service level is elastic according to demand. During load peaks that affect a specific service, that service can be scaled as needed through duplication. Tasks can be processed in parallel by multiple service instances.
  • Versioning: Application Programming Interfaces (APIs) can be versioned more effectively because individual services follow their own schema. Updates can be delivered as needed. Flexible language selection: Developers can choose the programming language for each microservice independently. For example, a special